Amazon ElastiCache for Redisのメジャーアップグレード方法をまとめてみた

quiver

2022.08.15

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Amazon ElastiCache for RedisはAWSが提供するRedisのマネージドサービスです。

2023年にElastiCache Redisの2系および3系がEOLを迎えることから、メジャーアップグレード方法を検討する機会がありましたので、共有します。

ElastiCache for Redis 2/3 の EOL

ElastiCache for Redis は 2.6.13から6.2まで幅広いバージョンに対応しています。

この内、2系と3系は2023年に EOL を迎えることが発表されています。

エンジンバージョン	コンソールから作成不可	CLI・API・CloudFormationから作成不可	自動アップグレード
2.x.x	2022/10/13 以降	2023/01/13 以降	2023/01/13 以降
3.x.x	2023/05/01 以降	2023/07/31 以降	2023/07/31 以降

EOL を迎えるエンジンは、まずはAWSコンソールから作成できなくなり、その後、CLI/API/CloudFormationなどから作成できなくなり、以降はメンテナンスウィンドウ中に 6.2 へ自動アップグレードされます。

アップグレードが必要なクラスターが存在する場合、AWSアカウント宛に以下のような案内が通知されているはずです。

Hello,

You are receiving this message because you have one or more Amazon ElastiCache for Redis clusters running version 3.x.x in the AP-NORTHEAST-1 Region.

ElastiCache for Redis version 3, originally released in October 2017, will reach its End Of Life (EOL) on July 31, 2023. We are providing you this notice to give you sufficient time to upgrade your Redis cluster(s). We recommend that you upgrade your cache cluster(s) to the latest available ElastiCache for Redis version before July 31, 2023. At this time, the latest version is 6.2, and it contains features including: JSON support, Redis Streams, performance improvements (including Enhanced IO), and data tiering as well as a various security and reliability updates.

[snip]

アップグレード方法

インプレース
Blue/Green

の2種類のアップグレード方法があります。

方法	インプレース	Blue/Green
詳細	既存の Redis クラスターを直接アップグレード	既存クラスターとは別に新規クラスターを作成し、切り替え
メリット	操作がシンプル。エンドポイントが変わらない。	ダウンタイムが短い。Data Tiering化などクラスターの作り直しを伴う構成変更にも対応
デメリット	構成によってはダウンタイムが長くなる	エンドポイントが変わる。手順が複雑。新クラスターの手動ウォームが必要
ロールバック	スナップショットからクラスターを作成	アプリのエンドポイントを旧クラスターに向ける

まずは、計画メンテナンスが可能か、インプレースのオンライン変更に伴うダウンタイムを許容できるかによって、インプレースまたはlue/Greenを選択しましょう。

1. インプレース方式

インプレース方式はクラスターの変更操作の一環としてバージョンを変えるだけのため、非常にシンプルです。余裕を持ったメンテナンス時間を確保できる場合や一時的なサービス断を許容できる場合、おすすめです。

Elasticache Redis はインプレースアップグレード中もAurora/RDS のような長時間のダウンタイムは伴わず、主にフェイルオーバーのタイミングで接続障害が発生します。

ただし、以下の様なクラスター構成の場合、ダウンタイムが長くなる可能性があります。

エンジンバージョンが 5.0.5 未満
レプリカがないスタンドアローン構成

(AWSドキュメントから)

Starting with Redis engine version 5.0.5, you can upgrade your cluster version with minimal downtime. The cluster is available for reads during the entire upgrade and is available for writes for most of the upgrade duration, except during the failover operation which lasts a few seconds.
You can also upgrade your ElastiCache clusters with versions earlier than 5.0.5. The process involved is the same but may incur longer failover time during DNS propagation (30s-1m).

検証環境でアップグレードを試し、ダウンタイムが許容範囲か検証しましょう。

また、以下のような構成変更はクラスターの作り直しが必要です。インプレースのバージョンアップはできないのでご注意ください。

大容量のキャッシュを扱えるData Tieringを利用したい
クラスター化(シャーディング)したい
at-rest暗号化したい

2. Blue/Green方式

Blue/Green方式はダウンタイム無しにバージョンアップしたい場合に向いています。

既存クラスターとは別に新規クラスターを作成し、切り替えのタイミングでアプリの向き先を新クラスターに向けます。

既存・新規クラスター間でのデータ同期には注意が必要です。

オンライン・マイグレーション機能を利用すると、ElastiCache RedisをEC2/オンプレなどでセルフホストされたRedisのレプリカにできますが、他のElastiCache Redisクラスターをソースとしたマイグレーションは対象外です(Online migration is designed for data migration from hosted Redis on Amazon EC2 or on-premise self-hosted Redis to ElastiCache for Redis and not between ElastiCache for Redis clusters.)

さらに、ElastiCache Redisはreplicaof/slaveof コマンドが禁止されているため、レプリケーションのターゲットになれません。

最新キャッシュが溜まっているウォーム状態でクラスターを切り替えたい場合、以下の流れでダブルライトしましょう。

(スナップショットから)移行先バージョンの新クラスターを作成
アプリを改修し、新旧クラスターに同じデータを書き込む(ダブルライト)。読み取りは旧クラスターから行う
新旧クラスターのキャッシュが同等になったタイミングで、読み書きを新クラスターだけにする
旧クラスターを削除

仮にRedisの全データに対してTTLを7日に設定している場合、7日以上ダブルライトすれば、新旧クラスター間のデータ差分を気にする必要はありません。

ダブルライトの事例としては、タップルは、サービス影響なし・ダウンタイムなしにメジャーアップグレードしています。

タップルにおける約4年越しのキャッシュストア大幅アップデート | CyberAgent Developers Blog

アップグレード先バージョンは？

Redis は基本的に後方互換性が維持されており、RDBでありがちなSQLの性能劣化のようなリスクは低いです。そのためか、ElastiCache Redisでは、任意の上位バージョンへアップグレードが可能です。

例えば、最も古いバージョンである 2.6.13 から最新の 6.2 へのアップグレードすら可能です。実際、EOL のドキュメントでは、2.x/3.xの移行先(Recommended Upgrade Target)として 6.2 が推奨されています。

バージョンごとの差異がまったく存在しないわけではないため、次のドキュメントからバージョンの差分を確認し、特別な事情がなければ最新の6.2へのアップグレードを検討しましょう。

リスク軽減のためにバージョンを抑えたい場合、5.0.6 がおすすめです。

クラスター変更時のダウンタイムが軽減され(5.0.5から)、最新のノードタイプ(5.0.6から)を選択できるためです。

ノードタイプどうする?

メジャーアップグレードはノードタイプを見直すよい機会です。

新しいノードタイプは、より安価で高性能な傾向があります。メジャーアップデートやリザーブドインスタンスの更新を期に、新しいノードタイプへ変更しましょう。

エンジンバージョンごとに利用可能なノードタイプに制限があり、最新ノードタイプ(M6g/R6g/T4g)はバージョン 5.0.6 以上で対応しています。

注意点として、5.0.6未満のクラスターをバージョンアップと同時に最新ノードタイプへは変更できません。一度、5.0.6以上へバージョンアップした上で、ノードタイプを変更してください。

対応しているクラスター変更パス

2.8/R4 → 6.2/R4
- バージョンだけを変更
2.8/R4 → 6.2/R5
- バージョンとノードタイプ(非最新)を変更
2.8/R4 → 6.2/R4 → 6.2/R6g
- バージョンを5.0.6以上に変更後、最新のノードタイプへ変更
5.0.6/R4 → 6.2/R6g
- 5.0.6以上のバージョンから、バージョンアップと同時に最新ノードタイプへ変更
2.8/R4 → スナップショット → 6.2/R6g
- スナップショットを経由してクラスターを新規作成する場合、バージョンアップと同時に最新ノードタイプへの変更が可能

対応していないクラスター変更パス

2.8/R4 → 2.8/R6g
- 5.0.6未満のバージョンは最新ノードタイプに対応していない
2.8/R4 → 6.2/R6g
- 5.0.6未満のバージョンから、5.0.6以上へのバージョンアップと最新ノードタイプへの変更は同時にできない

参考 : Amazon ElastiCache for Redisの各バージョンが対応しているノードタイプを調べてみた | DevelopersIO

データロス

ElastiCache はノード変更時にデータロストができるだけ起きないように設計されています。

The Amazon ElastiCache for Redis engine upgrade process is designed to make a best effort to retain your existing data and requires successful Redis replication.

Upgrading engine versions - Amazon ElastiCache for Redis

Redisはキャッシュサービスのため、データの永続性についてはRDBほどシビアでないはずです。

データロスがクリティカルな場合、Redis の使い方を間違えているかもしれません。これを機に、アプリケーションがRedisで管理すべきデータを見直しましょう。